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5 ASSET MANIPULATION OF COMPUTER GAMES USING A NETWORK 

The present application claims priority to U.S. Provisional Application No. 
60/426,006, filed November 14, 2002, U.S. Provisional Application No. 60/471,756, filed 
May 20, 2003, and U.S. Provisional Application No. 60/479,812, filed June 18, 2003, all of 
which is hereby incorporated by reference. 

1 0 BACKGROUND OF THE INVENTION 

The present invention relates to the advancement and enhancement of digital gaming 
and novel applications of digital information over networks and methods for implementing 
and using such invention. More specifically, the invention relates to ways of manipulating 
15 assets (e.g., items and dynamic content) in computer games using a network. 

The network ready gaming console and high performance wireless device markets, 
including personal digital assistants (PDAs) and handheld computers, are relatively nascent. 
Personal computers have had online gaming capabilities for some time, but, the communities 
and technologies available to and being developed for personal computers are not cohesive or 
20 universal. 



Currently, online gaming communities are very limited. There are effectively four 
types of online gaming communities: 1) Those supported by the producers of the games 
themselves; 2) Simple, uncopyrighted gaming websites (these sites typically offer the ability 
to play commonly known and unowned games, such as poker, chess, pool, and the like, via 
5 web applications (e.g., Java embedded in a web page)); 3) Fantasy sports sites (in these sites 
one's gaming performance is based on the performance of actual (i.e., real life) players and 
teams); 4) Online casinos (gambling sites for monetary return). 

In many computer games, users have the ability to acquire (e.g., a pistol) and create 
(e.g., crafting a sword) items in the game. Some games have mechanisms for users to trade 
10 or sell these items. However, these mechanisms within the game can be less than satisfactory. 
For example, an exchange of the item generally requires that the two users be logged into the 
game in order to execute the transfer of an item. 

Other limitations of current games are that they do not support the transfer of items 
outside of and between different games. The acquiring and creation of items is typically 
1 5 limited to within the game itself. 

Many games allow for advertising within in the game. Typically, the game developer 
programs the game to display the desired content to the user. The current mechanisms have 
met with limited success as, in order to change the content being displayed in a specific 
location, modifications to the game may be required. Additionally, many games have content 
20 that potentially could be dynamically controlled by a user. Unfortunately, there are no 

currently available mechanisms for allowing users and producers to easily create, sell, lease or 
otherwise manage dynamic content (e.g., advertising space) within a game. 
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Accordingly, it would be desirable to have innovative mechanisms that allow users to 
manipulate computer game items outside of and between games over a network. Additionally, 
it would be beneficial to have mechanisms that allow users and producers to create and 
manage dynamic content within a game. 
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SUMMARY OF THE INVENTION 

The present invention provides innovative mechanisms for manipulating assets in 
computer games over a network. In general, information about assets in one or more games is 
5 stored outside the game environment. The information can include attributes of the asset, 
ownership, conditions for a change in ownership, permissions, and the like. During execution, 
the game (or games) can access the information about the assets that is stored outside the 
game environment. 

By storing information about the assets outside the game environment, users can more 
10 efficiently and flexibly trade, sell, loan, lease, etc. the assets. Additionally, assets are not 
limited to a single game and inter-game transactions can be realized. Some specific 
embodiments of the invention are described below. 

In one embodiment, the invention provides a method for storing information about 
assets outside a game environment. An application programming interface (API) is provided 
15 that allows information about assets to be stored outside the game environment. A game is 
provided that calls the API in order to store information about the assets. During execution of 
the game, information is stored about the assets outside the game environment. Typically, the 
assets are items or dynamic content. 

In another embodiment, the invention provides a method for changing ownership of an 
20 asset outside a game environment. An offer from a first user is displayed for changing 
ownership of an item. An acceptance of one or more conditions specified in the offer is 
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received from a second user. Upon acceptance of the one or more conditions, the ownership 
of the item is changed to the second user outside the game environment. 

In another embodiment, the invention provides a method of lending or borrowing 
items without changing ownership. An offer from a first user to loan or borrow an item 
5 without changing ownership is displayed. An acceptance of one or more conditions specified 
in the offer is received from a second user. Upon acceptance of the one or more conditions, 
allowing the use of the item by a borrower, where the borrower is the first user if the offer was 
to borrow or the second user if the offer was to lend. The offer can also be a lease with a 
periodic payment amount as a condition. 

10 In another embodiment, the invention provides a method of dynamically changing 

content in a game over a network. Content to be presented in the game that can be changed 
over a network is defined, where the content is stored in data structures maintained by a server 
that is not executing a game that presents the content. The content to be presented in the game 
is transmitted over a network to the game. The game presents the content so that the content 

1 5 is dynamically changed 

In another embodiment, the invention provides a method of allowing access to 
dynamic content in a computer game. An offer from a first user is displayed for use of the 
dynamic content. An acceptance of one or more conditions in the offer is received from a 
second user. Upon acceptance of the one or more conditions, the second user obtains use of 
20 the dynamic content. Use of the dynamic content can include the ability to define and change 
the dynamic content. Dynamic content can be an image, a sound, an item, or any combination 
of these, including advertising. 
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With embodiments of the invention, transactions regarding assets (and any change in 
the data structures associated with the assets) can occur outside the game environment (e.g., 
separately from the game that utilizes the assets). This means that the game does not need to 
be executing (nor does the user have to be logged in depending on the game) for the 
5 transaction to occur. In some embodiments information about assets are stored on an asset 
server that is separate from the game server. In other embodiments, the game server can 
implement this functionality while it is still outside the game environment. 

Aspects of the invention provide for the integration of digital information with a 
platform that utilizes and builds upon that information to create a digital virtual world that 
10 seamlessly interfaces with the real world. This platform can be used by a variety of users to 
extend their capabilities past that of the real world and into the virtual world while the 
repercussions of those actions within the virtual world extend into the real world and real life 
of any such user. 

Other features and advantages of the invention will become readily apparent upon 
15 review of the following description in association with the accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a blocked diagram of an embodiment within a central server gaming 

system. 

FIG. 2 shows a blocked diagram of an embodiment in a peer-to-peer gaming system. 

FIG. 3 shows a block diagram of one embodiment of the invention. 

FIG. 4 illustrates components that may be present in devices and computer systems 
that implement the invention. 

FIG. 5 shows a flowchart of a process of changing the ownership of an item outside 
the game environment. 

FIG. 6 shows a flowchart of another process of changing ownership of an item. 

FIGS. 7A-7D illustrates data structures that can be utilized to facilitate the transaction 
shown in FIG. 6. 

FIG. 8 shows a flowchart of a process of obtaining the use of dynamic content in a 

game. 

FIG. 9 shows a flowchart of a process of selling the use of dynamic content. 

FIG. 10 shows a flowchart of a process granting exclusive access to an asset during 
game play. 



FIGS. 1 1 A and 1 IB show flowcharts that can be utilized for a multi-person 
transaction. 

FIG. 12 shows a block diagram illustrating a system where a content producer 
generates assets outside the game environment. 

5 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

In the description that follows, the present invention will be described in reference to 
embodiments that allow for asset manipulation in computer games over a network. More 
5 specifically, the embodiments will be described in reference to preferred embodiments. 
However, embodiments of the invention are not limited to any particular configuration, 
architecture, or specific implementation. Therefore, the description of the embodiments that 
follows is for purposes of illustration and not limitation. 

FIG. 1 shows a block diagram of an embodiment of the invention in a central server 
10 gaming system. Client 1 interacts through network 3 with a game server 5. The client can be 
gamers or games. Network 3, like all network representations shown herein, can be any 
network media that allows network devices to communicate. 

Game server 5 is the computer system that is responsible for operation of one or more 
games. Although shown as a single server, the game server can utilize multiple computer 
15 systems. 

Game server 5 communicates through network 7 with an asset server that can 
implement embodiments of the invention. Asset server 9 can store items for game server 5, 
facilitate the use of dynamic content within a game, allow multi-person transactions, allow 
content producers to generate items, and other features, as will be described in more detail 
20 below. Typically, the asset server is not executing a game, but communicates with games, 
gamers, advertisers, content producers, and the like. 
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Asset server 9 communicates through network 11 to clients 13. Clients 13 can be 
content producers, advertisers, gamers and the like. 

The central gaming system shown in FIG. 1 is illustrative of games where a central 
server is executing one or more games. For example, the games can be interacting sports 
games, online fantasy games, casino games, and the like. The games run on game server 5 
can be transient, meaning that the game has a definite start and finish or persistent meaning 
that the game is always running (unless down for updates or maintenance). 

FIG. 2 shows a block diagram of a peer-to-peer gaming system. Clients 51 interact 
through network 53 with each other and with an asset server 55. Clients 51 can be gamers or 
games. Typically, there is at least one game and at least one gamer. However, a single client 
system can execute a game, run the environment for a gamer and/or any combination of one or 
more of each. 

Asset server 55 can perform the similar features provided by asset server 9 of FIG. 1, 
just in a peer-to-peer gaming network. Asset server 55 communicates through network 57 to 
client 59. Clients 59 can be content producers, advertisers, and the like. 

The peer-to-peer gaming system shown in FIG. 2 differs from FIG. 1 in that one or the 
clients hosts the game or games. Typically, the games in a peer-to-peer gaming system are 
transient, but the games could be of persistent nature if so designed. 

Now that representative systems have been described, it may be beneficial to describe 
further details on the asset server in some embodiments. FIG. 3 shows a block diagram of the 
asset server. Asset server 101 interacts with clients or servers 103. Clients or servers 103 
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represent what can be gamers, games, game servers, game developers, content producers, 
publishers, marketing agencies, advertisers, and the like. 

Asset server 101 includes a user interface 105, which in some embodiments is 
accessed through a web browser or the game itself. User interface 105 can be utilized by 
5 gamers, content producers, advertisers, and the like. However, for the gamer, the user 
interface creates a community for multiple games. 

The most commonly available user interface is a World Wide Web site. This allows 
people to access the community site using their personal computers and Internet Web 
browsers (e.g., Netscape, Mozilla, AOL, Internet Explorer, etc.). Other user interfaces can be 
10 provided by the asset server which can be embedded directly in the games themselves. Using 
these user interfaces, people can access the community site and its functionality from within a 
game itself. 

The community site is where the gamer's identity exists. All data about the gamer can 
be kept and maintained on the community site (e.g., what games have been played, how many 

15 have been won, credit balance, how much has been spent and on what, sponsor information, 
the terms of any formal relationships with sponsors or other gamers, and billing information). 
The community site has a user interface by which its users can affect data and relationships of 
the community. This user interface can be accessible via several means (e.g., WAP, WWW, 
etc.) and provides the means by which a user can take certain actions (e.g., change billing 

20 information, enroll in a tournament, purchase credits, define the terms of sponsorship and 
sponsor another gamer, track high scores of other users, challenge another user to play, 
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redeem credits for prizes, develop characters, buy and sell virtual goods in the virtual 
marketplace, watch a tournament in progress, etc.). 

These actions affect the community and define the context under which the games are 
played. The community is persistent. This means that characters (i.e., gamers' alter egos) are 
5 not fleeting, but rather they are permanent entities in the virtual world (just as are their real 
world counterparts). Because they persist, history may be established. Gamers may rise to and 
fall from glory, gain and lose sponsorships, just like sports figures of the real world. The 
community site is what maintains this world and records its history. 

The underlying concept of the community aspect of the invention is to provide for the 
10 ability for the concept of a character and his/her game- worldly possessions to exist outside of 
and beyond the game. In fact, it allows those possessions to operate seamlessly in multiple 
game environments (e.g., a character who has a car in one game might also be able to use it in 
another game) should the content producers allow it. Such other features and functionality 
include but are not limited to virtual currency, virtual assets, a virtual marketplace, real world 
15 partnerships, real world payoffs, real world advertising, real world visibility, content on 
demand, and virtual world data management and storage. 

Returning to FIG. 3, asset server 101 also includes a database 107 that can utilized to 
store information about items and/or dynamic content outside the game environment. Further 
details of exemplary embodiments of the database will be described below in reference to 
20 FIGS. 7A-7D. 
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Additionally, asset server 101 is shown to include marketplace 109. Marketplace 109 
facilitates transactions regarding items in one or more games. Dynamic content manager 1 1 1 
is also shown in asset server 101 and can be utilized to manage dynamic content such as 
advertising space that is utilized during game play. 

5 The clients, servers and asset servers can be any form of computing device ranging 

from handheld devices to main frames. Typically, the servers posses more processing power 
than the clients but all may share common components. 

FIG. 4 shows a block diagram of components that can be present in clients, server and 
client/server systems. A central processing unit (CPU) bus 151 allows the various 
10 components of the computing device to communicate. A CPU 153 executes instructions or 
computer code which can be stored in a memory subsystem 155. Memory subsystem 155 
represents what is typically volatile memory. 

A display subsystem 157 is responsible for displaying information, images or text to 
users. A sound subsystem 159 is responsible for generating sound and may include one or 
15 more speakers. A network subsystem 161 allows that computing device or computer system 
to communicate over a network. 

A storage subsystem 163 is responsible for nonvolatile storage of computer code and 
data. Representative storage media include a hard drive 165, a floppy drive 167, a CD-ROM 
or DVD-ROM drive 169, or a solid state storage 171. 
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Handheld computing devices through more powerful servers typically include many of 
the components shown in FIG. 4. However, additional or fewer components may exist in any 
individual device. Nevertheless, FIG. 4 is fairly representative. 

In one aspect of the invention, an application programming interface (API) is provided 
that can be called by games that are executing or running. The API can provide many services 
including allowing information about assets to be stored outside the game environment. A 
game is provided (or generated) that calls the API in order to store information about the 
assets. During execution of the game, information is stored about the assets outside the game 
environment. As described above, an asset server can store this information in a database that 
is stored separate from the game server. 

By exposing an API by which game designers can include the features of a virtual 
gaming community, any game can become part of this multi-game community by utilizing the 
API. If the community site is analogous to the televised events and newspapers through 
which we follow our favorite heroes, then the game itself is the track or stadium or field in 
which they compete. The API allows the two to be linked and the games enable the contest. 
The game developer uses the API to connect the single game session with the community, 
giving the single session meaning within a larger context. 

The API can include secure methods for the authentication and authorization of 
gamers and can expose other behaviors of the community site (e.g., record and publish game 
results). Any game developer can have a community game by using the API. 
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The API can be accessible via the Internet and can be made available using modern 
remote procedure call protocols (e.g., SOAP, XML-RPC, CORBA, etc.). Support for 
additional protocols can be added according to developer demand. The system is flexible 
enough to allow game developers to easily register new games and game item types on the 
5 system without requiring that the system be reimplemented for each new game. 

In some embodiments, a data model and set of tools is developed by which game 
developers can easily add new games and define new game item types to the system. Game 
item types can be designed with an arbitrary number of game-specific properties. The 
community site is unaware of the significance of these properties. For example, when 
10 designing a car type, a game developer may decide that an attribute of the car may be "weight 
in kilograms." The developer is free to define the attribute, and to which game item type it 
belongs. This attribute is sent to the game when requested, where it has its significance. 

Moving from a description of representative hardware and interfaces, FIG. 5 shows a 
flowchart of a process of changing ownership of an item. As with all flowcharts shown 
15 herein, steps can be added, deleted, combined, and reordered without departing from the spirit 
and scope of the invention. 

At a step 201, an offer from a first user is displayed for changing ownership of an item. 
In one embodiment, the offer can be searched for in a marketplace and then the terms of the 
offer for the item are displayed. The marketplace can provide users with many advantageous 
20 search tools in order to locate items of interest. 
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The offer that is displayed will include one or more conditions that must be satisfied in 
order to change ownership of the item. The conditions can vary on the type of transaction that 
the offer represents. The following will describe various transactions and illustrate 
representative conditions to which they can be associated. 

The offer can specify the sale of an item. This transaction can be a fairly simple 
transaction where the condition of the sale is a price in a specified amount of currency. 

The offer can specify a trade, where a condition to be met is an item that is to be 
traded. Not all trades are of even-valued items, therefore other conditions can specify 
additional items for trade and/or currency as further conditions of the trade. 

The offer can specify an auction for the item, as an auction the condition may specify 
the date of the auction with an underlying condition that the winner be the highest bid. 
Additionally, other conditions can be a minimum bid (or reserve) for the auction, a favorable 
rating for the person winning the auction, and the like. 

The offer may represent a loan of the item. A condition of the loan may be the 
duration of the loan, which may be specified as a unit of time or any other type of 
measurement. At the end of the duration of the loan, ownership can automatically revert to 
the original owner. The owner can also specify one or more limitations on the borrower to 
effect the item. Similarly, the offer may represent an offer to borrow an item. 

Other types of offers can include leases and leases to own, where conditions specify 
lease duration, periodic payment amount, and potentially conditions that affect a permanent 
transfer of ownership. As can be seen, the type of transaction and the accompanying 
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conditions vary greatly depending upon the arrangement the owner of the item wishes to 
create. 

Returning back to FIG. 5, an acceptance of the one or more conditions in the offer is 
received from a second user at a step 203. The one or more conditions that are accepted will 
depend on the specific offer. 

Upon acceptance of the one or more conditions, the ownership of the item changes to 
the second user outside the game environment at a step 205. In this manner, the offer 
represents a true offer since it can be accepted and the transaction executes immediately. 

Although many games allow users limited capability to execute transactions to change 
the ownership of items, they typically require that each user be currently playing the game and 
possibly meet at an agreed upon location. Information about items, including ownership, can 
be stored outside the game environment on an asset server. This provides numerous 
advantages including that in which users do not have to be in the game environment in order 
to execute transactions regarding items usable within the game. Additionally, this allows 
items to be moved between games. For example, an item can have certain characteristics in 
one game and similar (or different) characteristics in another game. Embodiments of the 
invention allow items to move thorough transactions between different games. 

FIG. 6 shows a flowchart of a process of executing a transaction for an item. At a step 
25 1 , user 1 acquires item A. Item A can be acquired any number of ways including being 
found, bought, manufactured, and the like. As will be described below, information about the 
items can be stored in tables on the asset server. 
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At a step 253, user 1 defines terms A of a transaction for item A. Thus, the transaction 
terms or conditions specify under what circumstances ownership of the item will be changed. 
For example, in a very simple case, the condition could be the amount of currency that would 
be required to buy the item. 

FIG. 7A illustrates exemplary data structures that can be utilized to store information 
about items on the asset server. Asset server 301 stores information about items in one or 
more tables such as an items table 303. Items table 303 as shown indicates that item A is 
owned by user 1 . The tables can include different and additional fields so the tables that are 
shown herein are for illustrative purposes. 

Asset server 301 receives a message 305 that specify the terms of the transaction for 
item A. Asset server 301 processes the message and adds the terms or conditions for the 
transaction to a terms table 307 as shown in FIG. 7B. 

Returning now to FIG. 6, user 2 discovers items A with terms A. User 2 can discover 
this many ways but typically will be done using search functions through a marketplace. If 
user 2 finds the terms acceptable, user 2 agrees to terms A at a step 257. Once the terms are 
accepted, the transaction executes at a step 259. Typically, the asset server also verifies the 
conditions are met before the transaction executes. 

FIGS. 7C and 7D illustrate how acceptance of the terms and the transaction executing 
can change the associated data structures. As shown in FIG. 7C, asset server 301 receives a 
message 309 that indicates that user 2 agreed to terms A. 
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Asset server 301 processes message 309 and generates a transaction table 31 1. 
Transaction tables 311 stores the users that are involved, the item and references a terms table 
307 that specifies the terms of the transactions. These data structures can remain as a record 
of the transaction that transpired. 

5 Asset server 301 then updates items table 303 to indicate that user 2 is now the owner 

of item A. Notifications 313 are then sent to user 1 and user 2 that the transaction has 
completed. 

In some transactions, the ownership of the item will not change so items table 303 
could remain unchanged. For example, a loan can be implemented without changing 
10 ownership of the item. In some embodiments, the items table can store not only the 

ownership, but also possession. Additionally, FIG. 6 and 7A-7D have been described in 
reference to a transaction that changes ownership of an item. A similar process can be utilized 
when a user desires to sell or lease access to dynamic content in the game. 

Aspects of the present invention enable sponsorship in the gaming world. With the 
existence of an economy in the virtual world and the assignment of value to assets necessary 
for game play and competitiveness the ability to acquire assets is crucial to a gamer's success. 
As in real life, a gamer may put forth their own capital or attract sponsors to supply the capital 
in exchange for advertising rights among other things as determined by the details of any deal 
or contract between the individual and the sponsor. Sponsors may also sponsor series and 
individual events among other things for, but not limited to, advertising rights and advertising 
space as determined by the details of any deal or contract between the event or series producer 
and the advertiser or sponsor. 
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Although many games include advertising within the game, typically, advertising is 
hard coded into the computer game making dynamic changes to the ad showing on the ad 
space very nearly impossible. Additionally, users or gamers can also have their own 
advertising space. For example, in a car racing game, each car could include dynamic space 
5 such as advertising portions or space on the car. 

With embodiments of the invention, the use of space, sound, and items in a game can 
be more efficiently used as dynamic content and hence become opportunities for 
advertisement and product placement. Space, images, sound, items, etc. in the game can be 
dynamically updated without requiring modification of the game and users can sell or lease 
10 the dynamic content that they own. 

FIG. 8 shows a flowchart of a process of selling or leasing dynamic content. At a step 
351, an offer from a first user for advertising space is displayed. Typically, the offer will 
include one or more conditions that must be met for another user to gain access to the 
dynamic content. 

15 An acceptance of the one or more conditions in the offer is received from a second 

user at a step 353. Upon acceptance of the one or more conditions the second user is allowed 
to use the dynamic content at a step 355. 

Information about dynamic content can be stored in tables or any another data 
structure by the asset server. Thus, tables similar to FIGS. 7A-7D can be utilized in 
20 association with FIG. 9 that shows a flowchart of a process of a transaction relating to 
dynamic content. 
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At a step 401, user 1 defines dynamic content A. User 1 can be the game designer, 
content producer or gamer. In the case of the gamer, the gamer may not define the dynamic 
content but instead may acquire it by some other mechanism including buying it, creating it, 
acquiring an item that includes dynamic content, and the like. 

5 User 1 defines term A of the transaction for ad space A at a step 403. Accordingly, 

user 1 specifies one or more terms or conditions that when satisfied will fulfill the transaction 
for the ad space A. 

At a step 405, user 2 discovers space A with terms A. User 2 can discover this 
information through the use of search capabilities in a marketplace. 

10 At a step 407, user 2 agrees to terms A. The asset server can verify the terms are met 

and the transaction executes at a step 409. The transaction itself can be any kind of 
transaction including lease, sale, lease-to-own, auction, trade, loan, and the like. 

The above has described a transaction relating to dynamic content. Embodiments of 
the invention can also provide dynamically changing content in a game over a network. 

1 5 Content to be presented in the game that can be changed over a network is defined, where the 
content is stored in data structures maintained by a server that is not executing a game that 
presents the content. The content to be presented in the game is transmitted over a network to 
the game. The game presents the content so that the content is dynamically changed. The 
content can have a specific purpose or can be presented in a specific space, at a specific time, 

20 or as a result of a specific action or event in the game. 
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In dealing with transactions of assets, some embodiments of the invention implement 
an inclusive lock on an asset during game play where the asset is subject to a transaction. 
FIG. 10 shows a flowchart of a process of granting exclusive access to an asset during game 
play. 

At a step 451, the game requests and exclusive lock for an asset from the server. The 
server is typically the asset server, but in other embodiments a different server including the 
game server can be utilized for this purpose. 

It is determined at a step 453 whether the server allowed the exclusive lock. The 
exclusive lock should be granted if the asset was not already locked by another entity, game, 
transaction, trade, and the like. 

If an exclusive lock could not be acquired, the game can display an error for the gamer 
at a step 455. Otherwise, it can be determined if the game needs access to another asset at a 
step 457. If yes, the game requests an exclusive lock for that asset at step 45 1 . 

If the game does not need access to another asset, the game uses the one or more assets 
and updates their states on the server at a step 459. As mentioned above, the information 
about the assets, including their locked or unlocked states, can be stored in data structures that 
are maintained by the asset server. 

At a step 461, it is determined whether the game is finished using an asset. If the game 
is finished with an asset, the game relinquishes the lock on the asset on the server at a step 
463. Alternatively, locks can be granted for a specified amount of time which if not 
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relinquished will expire automatically. At a step 465, it is determined whether the game needs 
access to another asset. 

The process shown in FIG. 10 can be utilized to lock assets so that they cannot be 
utilized while they are subject a transaction. This can be utilized to prevent such things as 
5 multiple transactions relating to the same asset and/or use of the asset while a transaction is 
pending for the asset. 

Embodiments of the invention also provide the capability to have secure multi-person 
transactions. FIGS. 1 1 A and 1 IB illustrate a process that can be followed for these 
transactions. FIG. 1 1 A represents the process of the first person that is starting the transaction 
10 and FIG. 1 IB represents the process for any subsequent people. 

With regard to FIG. 1 1, at a step 501, a user creates a transaction and defines initial 
terms for the transaction. It is then determined if there are any additional terms which need to 
be defined or whether any existing terms need to be modified at a step 503. 

If changes to the terms for the transaction are desired, the user refines the terms for the 
15 transaction at a step 505. As will be made more clear, the processes in FIGs. 1 1 A and 1 IB are 
iterative processes. In general, whenever a user modifies terms of a transaction, the 
acceptance of the changed terms of the transaction are revoked so that each user has to 
explicitly accept the new (and potentially final) terms of the transaction. 

At a step 507 it is determined whether the server was able to establish the new terms 
20 and exclusively lock the relevant items. If not, the server indicates to the user which items 
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were unable to be locked at a step 509. Additionally, the server may indicate the reason why 
the lock could not be obtained. 

If the terms have been changed to the user's satisfaction, the server revokes any 
existing approvals of the terms at a step 511 since the terms of the transaction have changed. 
5 If there are no more additional changes to the terms, the user approves the transaction at a step 
513. It is then determined at a step 5 1 5 whether the terms approved by the user where the 
same terms that are currently stored by the server in the data base. 

If the terms that were approved were subsequently changed, the server indicates to the 
user that the terms have changed at a step 517. Subsequently, the approval of the terms will 
10 be revoked as shown. 

At a step 519 it is determined if all the participants to the transaction have approved 
the transaction. If not, it is determined at a step 521 whether the user's approval of the terms 
has been revoked. If yes, the negotiation process can continue once again at step 503. 
Otherwise, the user is waiting for all participants to approve the transaction. 

1 5 Once all the participants to the transaction have approved the transaction and the 

process has ensured that the terms that they approved are the current terms, the terms of the 
transaction are executed at a step 521. Executing the transaction can include updating data 
structures that are stored by the asset server with respect to the items, ownership, ad space, 
terms of the transactions, participants of the transaction, and the like. 

20 FIG. 1 IB shows the process for the second and subsequent participants in a multi- 

person transaction. At a step 551, a user identifies a transaction to participant. For example, 
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the user could identify a multi-person trade transaction that is displayed in a marketplace. 
Once the user identifies the transaction, the second and subsequent users proceed in the same 
process as the user that initiates the transaction. Thus, starting at step 503 the second and 
subsequent multi-person transaction follow the same process as described starting at step 503 
5 in FIG. 11 A. 

In many existing games, it is the content developer who is responsible for generating 
assets. The content producer can specify how assets are acquired or can be created by users 
within the game. With one aspect of the invention, content producers can indicate conditions 
in which the asset server can generate an asset. FIG. 12 shows a blocked diagram where the 
10 asset server creates an asset under terms or conditions specified by the content producer. 

FIG. 12 shows a content producer 601 in communication with an asset server 603. A 
user 605 and a game device 607 are shown in communication with asset server 603. For 
simplicity, many of the other potential elements of the system are not shown but they can be 
seen in reference to FIGS. 1-3. 

15 Content producer 601 contacts asset server 603 and specifies conditions, that once 

met, will allow creation of an asset. Once asset server 603 has the conditions for creating an 
asset, gamer 605 can contact asset server 603 and evaluate the conditions for creating an asset. 

If the gamer accepts the offer and fulfills the conditions, the asset server 603 can 
generate the asset and store the asset in a database specifying that the new asset belongs to 
20 gamer 605. Once the transaction is complete, the asset can be manipulated in any way that is 
allowed by the game or through asset server 603. In other words, from the gamer's point of 
view, the newly created asset is no different than any other asset. 
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By allowing a content producer to specify conditions upon which new assets can be 
created, game developers can create an additional market for these assets where none has 
exited previously. 

While the above is a complete description of preferred embodiments of the invention, 
various alternatives, modifications, and equivalents can be used. It should be evident that the 
invention is equally applicable by making appropriate modifications to the embodiments 
described. Therefore, the above description should be taken as limiting the scope of the 
invention that is defined by the metes and bounds of the appended claims along with their full 
scope of equivalents. 
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